|
Problems with HTTP Authentication
Problems with HTTP AuthenticationEmilio Casbas The HTTP protocol offers us a challenge-response authentication mechanism which can be used by a Web or proxy server to grant or refuse access to resources on the network. Nowadays, the Net is witness to millions of transactions, as well as providing both public and confidential data. The network makes it all possible, but in order to maintain security we must know who has got access to our sensitive data and who can perform privileged operations. One must be sure than unauthorised users cannot browse documents which they do not have access to. Servers must somehow find out who the user in question is and, using that information decide what kind of action they can take. Authentication is a technique of identification based on knowledge, that is - on something the user knows, like a password or a PIN number. HTTP provides natural functionality of HTTP authentication. In reality, HTTP defines two official authentication protocols: basic and digest. Here I will concentrate in particular on basic authentication, which is more widespread among clients and Web servers but also less secure.
Figure 1. Web servers on the Internet These are the scopes of using this method of authentication:
Figure 2. Web servers on an intranet
Figure 3. Proxy servers on the Internet A Brief Introduction to AuthenticationDigest authentication:
Basic authentication:
As one can quickly learn, basic authentication transmits the user:password pair to the server in plain text and as such should not be used for sensitive credentials, unless it is deployed in an encrypted environment such as SSL.
Figure 4. Proxy servers on an intranet A Practical ExampleAt this point we already know what HTTP authentication is and what consecutive steps of its operation are. From now on we will be looking at these stages in more depth and in practical perspective, using our Mozilla Web browser. We will need an extension which intercepts HTTP headers we work with. The extension in question is called livehttpheaders and can be downloaded from http://livehttpheaders.mozdev.org/. One installs it following the steps described on the page, in effect of which Mozilla will offer the option Live HTTP Headers, as shown in Figure 6.
Figure 5. Basic authentication
Figure 6. The option Live HTTP Headers Clicking on that new option will bring up the frame shown in Figure 7.
Figure 7. The frame Live HTTP Headers From this point we will be receiving information about HTTP headers for all web pages we visit, this way we have been able to intercept the headers explained below. Headers ExplainedThe client sends a standard HTTP request, asking for a certain resource. GET /doc/ecasbas/ HTTP/1.1\r\n Host: www.prueba.es\r\n User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Accept: text/xml,text/html;q=0.9, text/plain;q=0.8, image/png,*/*;q=0.1\r\n Accept-Language: en-us,en; q=0.7,es;q=0.3\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1, utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n HTTP/1.0 401 Unauthorized\r\n Date: Mon, 16 Jan 2006 11:17:51 GMT\r\n Server: Apache/2.0.55 (Unix) mod_ssl/2.0.55 OpenSSL/0.9.7g PHP/5.1.1\r\n WWW-Authenticate: Basic realm="ByPassword"\r\n Accept-Ranges: bytes\r\n Content-Length: 3174\r\n Content-Type: text/html\r\n X-Cache: MISS from www.prueba.es\r\n Connection: keep-alive\r\n The user's browser interprets this HTTP code 401 as an authentication request and displays the user:password prompt, showing in it the names of the host and of the realm. This stage is illustrated by Figure 8.
Figure 8. The frame Live HTTP Headers The client returns the request with entered user credentials GET /doc/ecasbas/ HTTP/1.1\r\n Host: www.unav.es\r\n User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Accept: text/tml+xml,text/html, image/jpeg,image/gif; q=0.2,*/*;q=0.1\r\n Accept-Language: en-us,en;q=0.7,es;q=0.3\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n Authorization: Basic ZWNhc2JhczpwcnVlYmE=\r\n Afterwards the server compares the information obtained from the client with its list of users and passwords. If authentication has failed, the server will resend the HTTP 401 authorisation request header. If the presented credentials are correct, the server displays the requested resource. Then the server proceeds to the resource in question. HTTP/1.0 200 OK\r\n Date: Mon, 16 Jan 2006 11:17:58 GMT\r\n Server: Apache/2.0.55 (Unix) mod_ssl/2.0.55 OpenSSL/0.9.7g PHP/5.1.1\r\n Last-Modified: Fri, 13 Jan 2006 10:31:02 GMT\r\n ETag: "125b019-5-f636a580"\r\n Accept-Ranges: bytes\r\n Content-Length: 5\r\n Content-Type: text/html\r\n X-Cache: MISS from www.prueba.es\r\n Connection: keep-alive\r\n In earlier fields we could see special fields which have been added to various HTTP headers. At stage 3, when the server sends a response with the 401 header, a special field is contained in the headers: WWW-Authenticate: Basic realm="ByPassword"\r\n The value "Basic" indicates that we're asking the browser to use basic authentication. The content of the string "realm" is an arbitrary string sent to show the user the realm of authentication. Figure X shows the Mozilla dialogue window asking the user to authenticate, showing the name of the realm and the host. The user fills in the form and sends it. The browser automatically returns the request. As shown earlier on, certain fields have been added to the standard HTTP request used here. Authorization: Basic ZWNhc2JhczpwcnVlYmE=\r\n This is when the Web browser sends up-to-date authorisation information to the server. It can be noticed that the field "Authorization" consists of two values. The keyword "Basic" indicates that credentials are sent as required by basic authentication. The data block following it is the actual credentials sent by the browser; although they do not appear there directly, they are not encrypted and merely encoded to base64. Cutting a long story short, base64 encoding represents arbitrary sequences of octets in the form that is not necessarily human-readable. Its encoding and decoding algorithms are simple, but on the other hand encoded data is typically by 33% larger than the original. In order to obtain more information about this scheme of coding one had better make use of the inset On the Net. Listing 1. Perl code for decoding base64-encoded strings like the one shown earlier
#!/usr/bin/perl
use MIME::Base64;
while (<>) {
print MIME::Base64::decode_base64($_);
}
Wielding the code from Listing 1 along with plain-text credentials, one can trivially decode the latter to the user:password format: ZWNhc2JhczpwcnVlYmE= --> base64Decode() --> "ecasbas:test" Deployment of "digest" authentication involves exactly the same process as in the case of basic authentication, with the only differences being the number of arguments provided by the browser and the format of returned credentials. Both aforementioned authentication schemes, "digest" and "basic", are used by clients and Web servers. Even so though, they should not be used as a means of protecting sensitive information or providing secure access. It is highly widespread to use the same user name and password for different services, in this case one should ensure that resources which we protect this way are not particularly sensitive and so that the same credentials are not used with other services, for instance mail or access to private information. Proxy AuthenticationThe sequences discussed above pertain to a client requesting from a Web server access to a protected resource. However, authentication could also be used in cases when a proxy requires authorisation to grant one access to a resource. Let us examine this situation as well, including what codes are shown when there is a proxy involved. Having configured a proxy server in our browser, we make a request to become able to surf the Web. GET http://www.google.com/ HTTP/1.1\r\n Host: www.google.com\r\n User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Accept: application/x-shockwave-flash, text/xml,application/xml,*/*;q=0.1\r\n Accept-Language: en-us,en;q=0.7,es;q=0.3\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Proxy-Connection: keep-alive\r\n The proxy responds by pointing out that we must authenticate ourselves to become able to browse the Internet. HTTP/1.0 407 Proxy Authentication Required\r\n Server: squid/2.5.STABLE12\r\n Mime-Version: 1.0\r\n Date: Mon, 16 Jan 2006 13:01:19 GMT\r\n Content-Type: text/html\r\n Content-Length: 3283\r\n Expires: Mon, 16 Jan 2006 13:01:19 GMT\r\n X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0\r\n Proxy-Authenticate: Basic realm= ""Proxy Authentication (user/passwd)""\r\n X-Cache: MISS from proxy.es\r\n Proxy-Connection: keep-alive\r\n
Figure 9. The frame Live HTTP Headers Our browser will then interpret this as a challenge/response for basic authentication and show us the login dialogue so that we can enter the required data. This is illustrated by Figure 9. Certain browsers do not interpret "realm" name properly and as a result some of them will indeed show the message "Proxy Authentication (user/passwd)" in the dialogue shown above; this particular case is different, but we will use it as an example. We enter the user name and the password, after which our client sends the following feedback data to the proxy: GET http://www.google.com/ HTTP/1.1\r\n Host: www.google.com\r\n User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Accept: application/x-shockwave-flash, text/xml, image/gif;q=0.2,*/*;q=0.1\r\n Accept-Language: en-us,en;q=0.7,es;q=0.3\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Proxy-Connection: keep-alive\r\n Proxy-Authorization: Basic ZWNhc2Jhc0B1bmF2Lm VzOnBydWViYTAx\r\n The proxy server internally checks whether the user name and the password are valid and grants us access to the resource. HTTP/1.0 200 OK\r\n Cache-Control: private\r\n Content-Type: text/html\r\n Content-Encoding: gzip\r\n Server: GWS/2.1\r\n Content-Length: 1408\r\n Date: Mon, 16 Jan 2006 13:05:40 GMT\r\n X-Cache: MISS from filter\r\n Proxy-Connection: keep-alive\r\n In case of proxy servers the HTTP code 407 (Proxy Authentication Required) is used instead of 401, moreover the header WWW-authenticate used with Web servers is now called Proxy-Authenticate. Barring those minor differences, the whole process is identical to the scenario of accessing a restricted Web resource. Table 1. Web server and proxy authentication
An Overview of HTTP AuthenticationBasic authentication is not a secure method of authenticating users. Passing credentials over the network in clear text does nothing to protect the user's identity. On the other hand, HTTP is not beyond employing additional authentication schemes or encryption mechanisms, the purpose of which is to increase and improve security of basic authentication. Despite the weakness of this mode of authentication it is, as we could see earlier, used in various environments, where the greatest threat is the presence of Single Sign On - that is, an individual's single set of credentials is used to confirm access rights to any resource on the network. If that is the case, it basically doesn't matter whether or not mechanisms of secure access using SSL, secure network-level connections (IPSEC), programs with secure login features etc., are used; even if only one resource uses this scheme of authentication, one could obtain immediate access to all the available services. An ideal field for deploying and using this kind of authentication are would be e.g. access to usage statistics of a Web server, or to any resource one does not consider unauthorised access to potentially threatening. On top of that, access authentication settings must be provided by the site administrator or by a generator program. They must never be chosen by users, as that would lead us back to the same problem as mentioned earlier. People are not in habit of using different credentials for different services and re-use them instead. ConclusionHTTP basic authentication is simple and convenient, but it is not a secure scheme. It should be used when the nature of access to information is to be private and not strictly necessary, as well as when using it cannot compromise security of other systems. People strive to use the same user name and password for many different purposes, as a result of which even if certain credentials are used in trusted environments and to control access to non-sensitive information, there is always a risk that the same credentials could grant one access to more important services such as e-mail, private documents or databases. With a network sniffer and several scripts for appropriate interpretation of intercepted traffic, using the aforementioned method it is possible to obtain hundreds of "user/password" pairs in mere minutes. In case of HTTP, authentication passwords traverse the network in clear text. Furthermore, headers with passwords are typically sent more than one time per connection - they are transmitted for every transaction within the lifetime of a single connection. This is related to the nature of HTTP, which does not preserve state information and makes it necessary to remind it of provided data in course of every connection established to a Web server or a proxy. In order to improve this authentication scheme or replace it with other, more secure methods, one should:
|
|
